The :read-only and :read-write pseudo-classes in CSS allow you to style form elements based on their editability state. They help indicate to users whether an input can be modified or is read-only.

How They Work

1
:read-only – Selects form elements that are not editable (e.g., elements with the readonly attribute).
2
:read-write – Selects form elements that are editable and can be changed by the user.
3
These pseudo-classes dynamically reflect the current state of the element.

Example: Using :read-only and :read-write

In this example, the editable input has a white background with a solid border, while the read-only input has a gray background and dashed border, clearly indicating which fields can be modified.

Best Practices

1
Use :read-only and :read-write to provide visual feedback about editable states of form elements.
2
Combine with :focus or :hover to enhance interactivity and UX.
3
Ensure visual cues are accessible and distinguishable, not relying solely on color.
4
Test behavior across different browsers and input types to ensure consistent styling.

Difficulty: 3/10

Topics: CSS pseudo-classes, form element states, user interaction styling

Scenario Questions

0-2 years experience

1
You're building a form where some fields should appear grayed out but still selectable — how would you style them using :read-only vs. :read-write?
2
A teammate says their input isn't styling correctly with :read-only — what are two common reasons this might happen?
3
If you set an input to readonly in HTML, but your CSS rule using :read-write is still applying, what’s likely wrong?

2-5 years experience

1
Our dynamic form toggles fields between editable and read-only based on user role — sometimes the styling breaks after state changes. How would you debug this using :read-only and :read-write?
2
We’re using a third-party form library that doesn’t set readonly attributes consistently. How would you ensure visual consistency for read-only states without modifying the library?
3
A user reports that a read-only field still looks clickable. How would you use :read-only and :read-write to fix the UX without touching JavaScript?

5-8 years experience

1
We have a legacy form system with hundreds of dynamically generated inputs — some use readonly, others use disabled or JS-controlled classes. How would you refactor the styling layer to unify read-only behavior using CSS pseudo-classes while minimizing regressions?
2
In a high-performance dashboard with 500+ read-only fields, we’re seeing layout thrashing. How might :read-write and :read-only impact rendering performance, and how would you optimize it?
3
Our design system uses custom components that simulate read-only state via CSS classes. What are the accessibility and maintainability tradeoffs of switching to native readonly attribute + :read-only pseudo-class?

8+ years experience

1
We’re migrating from a proprietary form framework to a standards-based one — many legacy components rely on JS-managed classes for read-only states. How would you design a phased migration strategy that preserves UX while adopting :read-only and :read-write without breaking existing workflows across 10+ teams?
2
Our global product supports 20+ languages and complex form layouts. Some locales treat read-only fields as non-interactive, others as selectable. How would you architect a CSS strategy using :read-only and :read-write that accommodates cultural UX expectations without duplicating styles?
3
A compliance audit flagged our forms for inconsistent read-only state representation. How would you enforce consistent use of :read-only and :read-write across 50+ micro-frontends, and what tooling or governance would you put in place to prevent drift?

Follow-up Questions

❓How would you style a read-only input differently from a disabled one?
❓What happens if you apply :read-write to a <div> with contenteditable?
❓Why might a developer prefer :read-only over adding a custom class like .readonly?